As used throughout this specification and claims, a “design” for an electronic device generally refers to information needed to construct that device. As can be appreciated from this broad definition, an electronic design has numerous aspects. Logical aspects of a design (sometimes known as a logical design or the “front end” design) include the identification of various functional elements. These functional elements may be specific electronic components (e.g., particular microprocessors, memory chips, and other components). These functional elements may also be more generic (e.g., an AND gate, an OR gate, a multiplexer, a resistor or capacitor having a certain resistance or capacitance value, etc.). The logical aspects of a design also include interconnections between inputs and outputs of these functional elements. Physical aspects of a design (also known as the “layout” or the “back end” design) include the actual size and location of various physical components associated with logical design elements. Notably, there is not necessarily a one-to-one correspondence between logical and physical elements. For example, a logical design element such as a gate must be implemented as an actual physical component. However, available chips and other physical components may have multiple “slots,” each of which contains a separate gate or other element having its own input and output pins. A single physical component may thus correspond to multiple logical elements. There are numerous other logical and physical design elements. In many cases, a particular element in the logical domain will have no directly corresponding element in the physical domain, and vice versa.
Traditionally, the schematic diagram has been the basis for electronic design. More specifically, front end designers often record the various functional elements of the logical design and the necessary interconnections on one or more graphical schematic diagrams. After completing the logical design, the front end designers then provide one or more sheets of schematic diagrams to the back end designers. The front end designers might also include a netlist (i.e., a list of all signals in the logical design and the logical elements connected to each signal) and information regarding constraints (e.g., restrictions on the manner in which components and nets can be placed and/or connected). The netlist is typically a separate document (or computer file), and the constraint information might be annotated onto the schematic or provided as a separate document. Using this front end information, the back end designers determine the actual placement of physical components on one or more circuit boards and route the physical connections (e.g., conductive circuit board traces) between the pins of those components. Frequently, the back end designers must also assign elements from the schematic to a particular physical component (e.g., assigning a gate to a slot of a chip). In some cases, the back end designer may add a physical component (e.g., a filter capacitor) to the layout design that is not represented on the schematics, or may make other types of changes that may implicitly affect the logical design.
This traditional approach to electronic design presents numerous problems. In the past, typical designs included numerous Small Scale Integration (SSI) and/or Medium Scale Integration (MSI) parts, and perhaps a few Large Scale Integration (LSI) parts. The SSI and MSI parts would typically have a limited number of pins, and the LSI parts might have on the order of 100 pins. With such designs, a schematic can be a useful representation. As designs have evolved, however, the schematic diagram has become less valuable. For example, current designs may include LSI or Very Large Scale Integration (VLSI) parts having up to thousands of pins. Such parts can be difficult or impossible represent on a single sheet of a schematic diagram. Drawing pieces of the same part on multiple drawing sheets can be tedious, and the resulting diagram is often confusing. Similarly, modern designs often have complex patterns of interconnections which run throughout the entire design, and must thus span numerous sheets of schematic diagrams. Following such interconnection patterns across multiple sheets is also tedious and confusing.
A schematic-driven design approach has numerous other shortcomings. Using traditional schematic-driven methods, front end and back end design are generally performed as serial processes with limited communication between the two. However, the complexity of electronic designs and market pressures to rapidly complete designs are continuing to increase. In such an environment, it is beneficial (and often necessary) for front and back end design tasks to be performed concurrently. In turn, this requires rapid (and sometimes frequent) exchange of design information between front and back ends. Existing methods inhibit such a rapid exchange, as entire design files (e.g., schematics, constraint data, net lists, etc.) must be transferred and then converted to an appropriate form. For example, a back end designer receiving an updated schematic must identify what symbols and/or interconnections have changed and then determine whether a part must be added, a trace added or re-routed, etc.
Traditional methods can also inhibit collaboration among multiple front-end designers. Separating a design project into manageably-sized portions and assigning those portions to different designers can be difficult. Moreover, managing design data as a collection of design data computer files limits the granularity with which design data can be “locked” to prevent conflicting edits by multiple users. File-based systems pose additional challenges for designers wishing to collaborate on a project. For example, a designer may often be unsure whether he or she has all of the files needed for a particular project. This also makes transfer of a design between designers a time-consuming process.
Traditional electronic design methods are increasingly less valuable in other ways. In addition to often having more LSI and VLSI parts, modern designs are becoming increasingly dense. In other words, designs must fit into increasingly smaller spaces. In turn, this requires printed circuit boards (PCBs) to have more and more layers. Modern designs also have increasing numbers of high speed signals. These factors make constraints upon the physical design more and more critical. Both front and back end designers must be able to track, access and/or modify these constraints. However, existing methods for constraint management become less useful as designs become more complex. Constraint data must often be synchronized among multiple users in real time, and waiting for an updated schematic (with revised constraint annotations) or a separate constraint document can require too much time. More important, lack of an automated system for synchronizing constraint data may result in a failure to effectively communicate constraint data between front and back ends.
Traditional design methods present other challenges for numerous persons working in parallel, particularly when those persons are in widely dispersed locations. For example, logical and/or layout design may be performed by teams of engineers working in different cities (or even in different countries). Various design tasks may be outsourced to other companies. Still other groups (e.g., manufacturing, purchasing) located in other locations may have need for the information contained in the layout and/or logical design data. Ensuring that all of these groups have the appropriate software needed to edit or view design data can impose significant administrative burdens. Yet a further complication arises when trying to limit the type of information accessible by certain groups. For example, purchasing department personnel may need access to design data when determining which parts to order, but do not need the ability to edit that design. As another example, it would be highly advantageous if a company could more easily assign a design task to an outside designer working for another company, provide that designer with the necessary software tools for the assigned task, and limit the designer's access to design data relevant to that task.
For these and numerous other reasons, there remains a need for improved systems and methods for electronic design automation.